如何基于BFE做灰度发布
1. 灰度发布的原理
互联网业务的研发提倡“小步快跑，快速迭代”。这要求在保证7*24小时不中断服务的前提下，可以高频度的升级服务，这就对“灰度发布”提出了需求。
灰度发布（又名金丝雀发布，Canary Release）是指在黑与白之间，能够平滑过渡的一种发布方式（来自百度百科）。
从流量转发的角度，灰度发布的原理如下图所示。用户流量由负载均衡器转发给服务。服务的部署分为正式服务和测试服务。由负载均衡器执行灰度发布策略，将符合条件的灰度流量转发给测试服务。
图1 灰度发布的原理
灰度策略可能包括两类：
(1) 按照一定的流量特征来选择灰度流量。可能作为流量选择的特征包括：用户来源地，特殊的请求标签等。
(2) 按照一定的流量比例来选择灰度流量。例如，可以控制选择1%的流量作为灰度流量。
2. BFE对于灰度发布的支持
BFE对基于流量特征和基于流量比例这两种灰度策略都提供了支持。
2.1 基于流量特征的灰度策略支持
利用BFE的路由转发表，可以实现基于特征的灰度策略。
在BFE中，对于每个租户都可以独立设置基础转发表、高级转发表和默认转发规则。图2和图3展示了利用高级转发表来实现基于特征的灰度策略的例子。
在本例中，包括A、B、C、D、E共5种服务。其中A、B、C、D这四种服务都使用基础转发表中的配置来完成匹配，E服务作为默认的服务（如图2所示）。
图2 在灰度发布前的转发配置
对于服务D，原本只在基础转发表中进行了配置。后来因为要进行灰度测试，于是在基础转发表中将www.c.c.com对应的目标集群设置为保留字“ADVANCED_MODE”（意为透传至高级转发表继续处理）；同时在高级转发表中增加2条规则（基于BFE的条件表达式来描述匹配条件），将在cookie中key为deviceid、值的前缀为“x”的请求转发到D1这个灰度试验集群，将其它Host为www.c.com的流量仍然转发至D集群（如图3所示）。
图3 实现基于特征的灰度发布
除了利用cookie外，也经常使用Header和query中的信息来区分测试流量。对于这些字段，在BFE中也有专用的条件原语用于描述相关的特征。可以在下面的链接中查看BFE支持的条件原语。
https://github.com/bfenetworks/bfe/blob/develop/docs/zh_cn/condition/condition_primitive_index.md
2.2 基于流量比例的灰度策略支持
利用BFE提供的内网流量调度机制，可以实现基于流量比例的灰度策略。
图4 基于流量比例的灰度策略
为了配合基于比例的灰度发布，可以常态准备2个子集群D1和D2。在BFE中，将2个子集群的分流比例设置为1%和99%。
在做新功能上线的时候，新版本的程序首先在D1子集群上线。使用1%的流量，经过一段时间的验证无误之后，再将新版本的程序上线至D2子集群。
可以在下面的链接中查看对子集群设置分流权重的方法
https://github.com/baidu/bfe-book/blob/version1/operation/configuration/proxy.md
3. 基于BFE控制面的操作
目前BFE的控制面组件已经开源发布。在安装BFE的控制面组件后，对于基于流量特征的灰度发布和基于流量比例的灰度发布，都可以直接登录BFE的dashboard来操作，或者通过调用BFE API提供的接口来操作。
在BFE的Dashboard上操作的说明，见下面的链接：
对于路由转发规则的配置：
https://github.com/bfenetworks/dashboard/blob/develop/docs/zh-cn/user-guide/tenant-view/route.md
对于子集群分流比例的配置：
https://github.com/bfenetworks/dashboard/blob/develop/docs/zh-cn/user-guide/tenant-view/backend.md
图5 使用BFEDashboard配置路由转发规则
4. 总结
“灰度发布”是互联网业务研发所需的重要能力。BFE对于灰度发布的两种方式（基于流量特征的灰度发布、基于流量比例的灰度发布）都提供了支持。结合已经开源的BFE控制面组件，可以使用BFE Dashboard或BFE API完成灰度发布的相关配置。
注：本文章中包含多个指向github的链接。可以通过点击左下方的“阅读原文”来访问这些链接。
欢迎关注“BFE开源项目”微信公众号，获得本项目的更多更新。谢谢！